로드 밸런서 아키텍처 및 운용 안내서

1. 서론: 현대 분산 시스템의 심장, 로드 밸런서

현대 컴퓨팅 환경은 폭증하는 트래픽과 끊임없는 서비스 가용성에 대한 요구에 직면해 있다. 이러한 도전에 대응하기 위해 시스템 아키텍처는 단일 고성능 서버에 의존하는 방식에서 다수의 서버가 협력하여 부하를 분산하는 방식으로 진화하였다. 이 패러다임의 전환 중심에는 로드 밸런서(Load Balancer)가 자리 잡고 있다. 로드 밸런서는 단순한 트래픽 분배 장치를 넘어, 현대 분산 시스템의 가용성, 확장성, 성능 및 보안을 보장하는 핵심 구성 요소로 기능한다.

1.1 로드 밸런싱의 필연성: Scale-Up에서 Scale-Out으로의 패러다임 전환

시스템의 처리 용량을 증대시키는 접근법은 크게 두 가지로 나뉜다. 첫째는 스케일업(Scale-Up) 또는 수직 확장(Vertical Scaling)으로, 기존 서버의 하드웨어 사양(CPU, RAM, 저장 장치 등)을 고성능 부품으로 교체하여 성능을 향상시키는 방식이다.1 스케일업은 아키텍처 변경 없이 성능을 높일 수 있어 구현이 비교적 간단하다는 장점이 있다.1 그러나 고성능 하드웨어는 비용이 기하급수적으로 증가하며, 물리적인 성능 향상에는 명백한 한계가 존재한다. 결정적으로, 서버 한 대가 모든 부하를 감당하므로 해당 서버에 장애가 발생할 경우 서비스 전체가 중단되는 단일 장애점(Single Point of Failure, SPOF) 문제를 해결하지 못한다.1

이러한 한계를 극복하기 위해 등장한 것이 스케일아웃(Scale-Out) 또는 수평 확장(Horizontal Scaling)이다.1 스케일아웃은 기존 서버와 유사한 사양의 서버를 여러 대 추가하여 클러스터를 구성하고, 들어오는 요청을 여러 서버에 분산하여 처리하는 방식이다.5 이 방식은 필요에 따라 서버를 유연하게 추가하거나 제거할 수 있어 탁월한 확장성을 제공하며, 일부 서버에 장애가 발생하더라도 나머지 서버를 통해 서비스를 지속할 수 있어 고가용성을 확보할 수 있다.1 하지만 다수의 서버를 운영함에 따라 아키텍처가 복잡해지고, 각 서버 간의 데이터 일관성을 유지해야 하는 새로운 과제가 발생한다.1 바로 이 지점에서 여러 서버로 트래픽을 지능적으로 분배하고 관리하는 로드 밸런서의 필요성이 필연적으로 대두된다.1

1.2 로드 밸런서의 핵심 역할과 가치

로드 밸런서는 클라이언트와 서버 팜(Server Farm) 또는 서버 풀(Server Pool)이라 불리는 서버 그룹 사이에 위치하는 중개자(intermediary)이다.7 클라이언트로부터의 모든 요청을 단일 진입점(Single Entry Point)에서 받은 후, 사전에 정의된 규칙과 알고리즘에 따라 가장 적절한 백엔드 서버로 전달하는 역할을 수행한다.9 이를 통해 로드 밸런서는 현대 시스템 아키텍처에서 다음과 같은 네 가지 핵심 가치를 제공한다.

1. 고가용성 (High Availability): 로드 밸런서는 주기적인 상태 확인(Health Check)을 통해 백엔드 서버의 장애 여부를 실시간으로 감지한다.4 만약 특정 서버에 장애가 발생하면, 해당 서버를 서비스 풀에서 자동으로 제외하고 정상적으로 작동하는 다른 서버로만 트래픽을 전달하여 서비스 중단을 방지한다.12 이를 통해 시스템은 일부 구성 요소의 실패에도 불구하고 전체 서비스를 안정적으로 유지할 수 있다.16

2. 확장성 (Scalability): 트래픽이 급증할 경우, 관리자는 새로운 서버를 서버 풀에 추가하기만 하면 된다. 로드 밸런서는 추가된 서버를 자동으로 인식하여 트래픽 분산 대상에 포함시킨다.8 반대로 트래픽이 감소하면 불필요한 서버를 제거하여 비용을 절감할 수 있다. 이처럼 로드 밸런서는 시스템이 트래픽 변화에 탄력적으로 대응할 수 있는 기반을 제공하여 병목 현상을 방지하고 자원의 효율적 사용을 가능하게 한다.5

3. 성능 최적화 (Performance Optimization): 특정 서버에 부하가 집중되는 것을 막고 모든 서버에 부하를 균등하게 분산함으로써, 각 서버가 최적의 상태에서 요청을 처리하도록 보장한다.5 이는 전체 시스템의 응답 시간을 단축하고 처리량(Throughput)을 극대화하여 사용자 경험을 향상시킨다.13

4. 보안 강화 (Security Enhancement): 로드 밸런서는 외부 클라이언트와 내부 서버 사이의 관문 역할을 하므로, 중요한 보안 계층으로 기능할 수 있다.8 트래픽을 모니터링하여 악성 콘텐츠나 비정상적인 요청 패턴을 필터링하고, 분산 서비스 거부(DDoS) 공격과 같은 대규모 공격 트래픽을 여러 서버로 분산시켜 그 영향을 최소화할 수 있다.5 또한 네트워크 방화벽 그룹과의 연동을 통해 추가적인 보안 정책을 적용하는 통로가 되기도 한다.8

2. 로드 밸런서의 기본 원리와 핵심 기능

로드 밸런서의 역할을 이해하기 위해서는 그 내부 동작 원리와 시스템의 안정성을 보장하는 핵심 기능들에 대한 깊이 있는 분석이 선행되어야 한다. 가상 IP를 통한 단일 진입점 제공부터 서버의 상태를 감시하고 네트워크 주소를 변환하는 기능에 이르기까지, 로드 밸런서는 복잡한 네트워크 상호작용을 추상화하여 안정적인 서비스 제공을 가능하게 한다.

2.1 작동 원리: 가상 IP(VIP)와 실제 서버(Real Server)의 상호작용

로드 밸런서의 가장 기본적인 작동 원리는 가상 IP 주소(Virtual IP Address, VIP)를 통해 구현된다.10 클라이언트는 실제 백엔드 서버들의 개별 IP 주소를 알지 못한다. 대신, 로드 밸런서가 외부에 대표로 노출하는 단일 IP 주소, 즉 VIP로 모든 요청을 전송한다.21

로드 밸런서는 이 VIP로 들어온 요청을 수신한 후, 내부적으로 설정된 로드 밸런싱 알고리즘에 따라 백엔드 서버 풀에 속한 여러 실제 서버(Real Server) 중 하나를 선택하여 요청을 전달(forwarding)한다.9 이 과정에서 네트워크 주소 변환(NAT) 기술이 사용되어, 요청 패킷의 목적지 IP 주소가 VIP에서 선택된 실제 서버의 IP 주소로 변경된다. 서버가 요청을 처리한 후 생성된 응답은 다시 로드 밸런서를 거쳐 클라이언트에게 전달되며, 이때 출발지 IP 주소는 실제 서버의 IP에서 VIP로 다시 변환된다.

이러한 메커니즘을 통해 클라이언트 입장에서는 오직 하나의 서버(VIP를 가진 로드 밸런서)와 통신하는 것처럼 보이게 되며, 백엔드의 복잡한 서버 구성과 장애 상황은 완전히 은닉된다.21 이는 시스템의 유연성과 관리 용이성을 크게 향상시키는 핵심 원리이다.

2.2 주요 기능 심층 분석

로드 밸런서는 단순한 트래픽 분배를 넘어 시스템의 안정성과 효율성을 보장하기 위한 다양한 부가 기능을 수행한다. 이 중 상태 확인, 네트워크 주소 변환, DSR, 터널링은 가장 핵심적인 기능들이다.

2.2.1 Health Check (상태 확인)

상태 확인은 로드 밸런서가 백엔드 서버의 서비스 가능 여부를 주기적으로 점검하여, 비정상 상태의 서버로는 트래픽을 보내지 않도록 하는 기능이다. 이는 고가용성 아키텍처의 근간을 이룬다.9 상태 확인은 OSI 모델의 여러 계층에서 각기 다른 방식으로 수행될 수 있다.

• L3 (ICMP 방식): 가장 기본적인 단계로, ICMP(Internet Control Message Protocol) ping 요청을 서버로 보내 응답이 오는지 확인한다.9 이는 서버의 IP 주소가 네트워크상에서 도달 가능한지를 판단하지만, 서버의 운영체제나 애플리케이션 서비스가 정상적으로 동작하는지 여부는 확인할 수 없다.

• L4 (TCP/UDP Port 방식): 전송 계층에서 동작하며, 특정 TCP/UDP 포트로의 연결을 시도한다. TCP의 경우, 3-way handshake를 시도하여 SYN-ACK 응답을 받으면 포트가 열려 있고 관련 서비스 데몬이 실행 중이라고 판단한다.9 부하를 줄이기 위해 완전한 연결을 맺지 않고

SYN-ACK 수신 후 RST를 보내 연결을 끊는 TCP Half-Open 방식도 사용된다.23 이 방식은 L3보다 정교하게 서비스의 동작 여부를 확인할 수 있다.

• L7 (Application 방식): 가장 정교한 방식으로, 실제 애플리케이션에 HTTP 요청을 보내 응답을 확인한다.9 예를 들어,

/health와 같은 특정 상태 확인 엔드포인트에 GET 요청을 보내 HTTP 200 OK 상태 코드가 반환되는지, 또는 응답 본문에 “OK“와 같은 특정 문자열이 포함되어 있는지 검사한다.4 이 방식은 애플리케이션의 로직 수준까지 정상 동작 여부를 가장 정확하게 판단할 수 있지만, 로드 밸런서와 백엔드 서버 모두에 가장 큰 부하를 준다.

상태 확인은 요청을 보내는 주체에 따라 Active Health Check와 Passive Health Check로 나눌 수도 있다.

• Active Health Check: 로드 밸런서가 주기적으로 백엔드 서버에 테스트 요청(예: ping, TCP 연결 시도, HTTP GET)을 보내 상태를 명시적으로 확인하는 방식이다.25

• Passive Health Check: 로드 밸런서가 별도의 테스트 요청을 보내지 않고, 실제 클라이언트로부터 받은 트래픽을 처리하는 과정에서 발생하는 서버의 응답(예: 연결 실패, 타임아웃, HTTP 5xx 에러)을 모니터링하여 장애를 감지하는 방식이다.26 이 방식은 Active 방식의 점검 주기 사이에 발생하는 순간적인 장애를 더 빠르게 감지할 수 있는 장점이 있다.

L7 상태 확인의 정교함은 시스템의 신뢰성을 높이는 데 기여하지만, 동시에 아키텍처 설계상의 위험을 내포한다. 만약 상태 확인 엔드포인트(예: /health)가 데이터베이스 연결 확인과 같은 외부 시스템 의존성을 포함하도록 설계되었다면, 이는 장애 전파(cascading failure)의 원인이 될 수 있다. 예를 들어, 데이터베이스가 일시적으로 느려지거나 장애가 발생하면, 모든 애플리케이션 서버의 /health 엔드포인트는 비정상 응답을 반환하게 된다.29 로드 밸런서는 이를 보고 모든 서버가 다운되었다고 판단하여 서비스 풀에서 전부 제외시키고, 결국 데이터베이스의 일시적 문제가 애플리케이션 전체의 서비스 중단으로 이어지는 심각한 상황을 초래할 수 있다. 따라서 이상적인 상태 확인 엔드포인트는 외부 의존성을 철저히 배제하고, 해당 인스턴스 자체의 상태만을 독립적으로 검증하도록 설계해야 한다. 이는 로드 밸런서 설정뿐만 아니라 백엔드 애플리케이션 설계 시에도 반드시 고려해야 할 중요한 아키텍처 원칙이다.

2.2.2 네트워크 주소 변환 (NAT, Network Address Translation)

NAT는 로드 밸런서가 사설 IP 주소와 공인 IP 주소를 상호 변환하여 내부 네트워크를 외부로부터 격리하고 보호하는 핵심 기술이다.9 로드 밸런싱 환경에서는 주로 두 가지 형태의 NAT가 사용된다.

• SNAT (Source NAT): 내부 서버가 외부 인터넷으로 응답을 보내거나 새로운 연결을 시작할 때 사용된다. 출발지 IP 주소가 서버의 사설 IP에서 로드 밸런서의 공인 IP 주소로 변환된다.9 이를 통해 외부에서는 모든 응답이 단일 로드 밸런서로부터 오는 것처럼 보이게 된다.

• DNAT (Destination NAT): 외부 클라이언트의 요청이 로드 밸런서로 들어올 때 사용된다. 목적지 IP 주소가 로드 밸런서의 공인 VIP에서 로드 밸런싱 알고리즘에 의해 선택된 실제 서버의 사설 IP 주소로 변환된다.9

2.2.3 DSR (Direct Server Return)

DSR은 로드 밸런서의 부하를 획기적으로 줄일 수 있는 고급 네트워크 구성 방식이다.4 일반적인 구성에서는 클라이언트의 요청과 서버의 응답 트래픽이 모두 로드 밸런서를 경유한다. 하지만 DSR 구성에서는 클라이언트의 요청만 로드 밸런서를 거치고, 서버가 처리한 응답은 로드 밸런서를 거치지 않고 라우터를 통해 클라이언트에게 직접 전달된다.9

이 방식은 응답 트래픽의 양이 요청에 비해 훨씬 큰 서비스(예: 비디오 스트리밍, 대용량 파일 다운로드)에서 특히 유용하다. 응답 트래픽이 로드 밸런서를 우회함으로써 로드 밸런서의 네트워크 대역폭과 처리 부하를 크게 절감할 수 있기 때문이다.9

2.2.4 터널링 (Tunneling)

터널링은 하나의 네트워크 프로토콜 데이터 패킷을 다른 프로토콜 패킷 내부에 캡슐화하여 전송하는 기술이다.9 로드 밸런싱 컨텍스트에서는 주로 DSR과 같은 특정 네트워크 구성을 구현하거나, 지리적으로 분산된 데이터 센터 간에 트래픽을 전달하는 GSLB(Global Server Load Balancing) 등에서 활용될 수 있다.31 데이터는 가상의 터널을 통해 전달되며, 출발지와 목적지에서만 캡슐화 및 역캡슐화가 이루어져 중간 네트워크 장비들은 내부 데이터를 인지하지 못한다.10

3. 로드 밸런싱 알고리즘: 트래픽 분산의 미학

로드 밸런서의 핵심은 ’어떤 서버에 다음 요청을 보낼 것인가’를 결정하는 로드 밸런싱 알고리즘에 있다. 이 알고리즘은 시스템의 성능, 효율성, 공정성을 좌우하는 중요한 요소로, 서비스의 특성과 요구사항에 따라 신중하게 선택되어야 한다. 알고리즘은 크게 서버의 현재 상태를 고려하는지 여부에 따라 정적 방식과 동적 방식으로 나뉜다.

3.1 알고리즘의 두 가지 패러다임: 정적(Static) vs. 동적(Dynamic)

• 정적 로드 밸런싱 (Static Load Balancing): 이 방식의 알고리즘들은 서버의 현재 부하 상태나 응답 시간과 같은 동적인 요소를 고려하지 않고, 사전에 정의된 고정된 규칙에 따라 트래픽을 분산한다.35 대표적으로 라운드 로빈, 가중 라운드 로빈, IP 해시 방식이 여기에 속한다. 구현이 매우 간단하고 계산에 필요한 오버헤드가 적어 빠른 처리가 가능하다는 장점이 있다.36 하지만 실제 서버들의 부하가 불균일한 상황에서는 특정 서버에 과부하가 발생하는 것을 막지 못할 수 있다.8

• 동적 로드 밸런싱 (Dynamic Load Balancing): 이 방식의 알고리즘들은 트래픽을 분산하기 전에 각 서버의 현재 상태, 예를 들어 활성 연결 수나 응답 시간 등을 실시간으로 확인한다.13 최소 연결, 최소 응답 시간 방식 등이 대표적이다. 서버의 실제 부하를 반영하여 더 지능적이고 공정하게 트래픽을 분산할 수 있어 효율성이 높다.18 그러나 서버 상태를 지속적으로 모니터링하고 계산하는 데 추가적인 시스템 자원과 오버헤드가 발생하며, 알고리즘 자체가 더 복잡하다.36

3.2 주요 알고리즘 상세 분석

각 알고리즘은 고유한 동작 원리와 장단점을 가지며, 특정 시나리오에 더 적합하다.

3.2.1 라운드 로빈 (Round Robin)

• 원리: 가장 단순하고 고전적인 정적 알고리즘으로, 클라이언트로부터 들어오는 요청을 서버 목록에 따라 순서대로 하나씩 할당한다.8 예를 들어 3대의 서버(A, B, C)가 있다면, 첫 번째 요청은 A, 두 번째는 B, 세 번째는 C로 가고, 네 번째 요청은 다시 A로 돌아가는 방식이다.39

• 수식적 표현: 다음 요청을 받을 서버의 인덱스(next_server_index)는 현재 요청을 처리한 서버의 인덱스(current_index)와 총 서버의 수(N)를 이용하여 다음과 같이 간단한 모듈로 연산으로 결정된다.

코드 스니펫

$next\_server\_index = (current\_index + 1) \pmod{N}$

• 적합한 환경: 모든 백엔드 서버의 사양이 동일하고, 각 요청을 처리하는 데 소요되는 시간이 거의 일정한 경우에 가장 공정하고 효과적으로 동작한다.5

3.2.2 가중 라운드 로빈 (Weighted Round Robin, WRR)

• 원리: 라운드 로빈 방식의 변형으로, 각 서버의 처리 능력에 차이가 있을 때 사용된다. 관리자는 각 서버에 가중치(weight)를 미리 할당하며, 로드 밸런서는 이 가중치에 비례하여 요청을 분배한다.8 예를 들어 서버 A의 가중치가 5, 서버 B의 가중치가 2라면, 7번의 요청 주기 동안 A는 5번, B는 2번의 요청을 받게 된다.8

• 의사 코드: 가중치를 관리하는 간단한 의사 코드는 다음과 같이 표현할 수 있다. 서버 S_i에 가중치 W_i가 할당된 경우, 총 sum(W)번의 요청 주기 동안 각 서버 S_i는 W_i번의 요청을 처리하도록 분배한다.

// Pseudocode for Interleaved Weighted Round Robin
// N: number of servers, W: array of weights
// gcd: greatest common divisor
i = -1
cw = 0
gcd_W = gcd(W_1, W_2,..., W_N)

while (true):
i = (i + 1) mod N
if i == 0:
cw = cw - gcd_W
if cw <= 0:
cw = max(W_1, W_2,..., W_N)

if W_i >= cw:
return S_i

• 적합한 환경: 서버 풀 내에 서로 다른 사양의 서버들이 혼재되어 있을 때, 고사양 서버에 더 많은 트래픽을 할당하여 자원 활용률을 최적화할 수 있다.10

3.2.3 최소 연결 (Least Connection)

• 원리: 대표적인 동적 알고리즘으로, 요청이 들어오는 시점에 서버들이 현재 처리 중인 활성 연결(active connection) 수를 확인하여 그 수가 가장 적은 서버에게 다음 요청을 할당한다.5

• 수식적 표현: N개의 서버 S_1, S_2,..., S_N이 있고, 각 서버 S_i의 현재 활성 연결 수가 C_i일 때, 다음 요청은 아래 조건을 만족하는 서버 S_target으로 전달된다.

코드 스니펫

$S_{target} = \underset{S_i \in \{S_1,..., S_N\}}{\arg\min} C_i$

• 적합한 환경: 각 클라이언트의 세션 유지 시간이 길거나, 요청마다 처리 시간이 크게 달라 라운드 로빈 방식으로는 부하가 불균일해질 수 있는 환경에 매우 효과적이다.5

3.2.4 가중 최소 연결 (Weighted Least Connection)

• 원리: 최소 연결 방식과 가중 라운드 로빈 방식을 결합한 동적 알고리즘이다.13 각 서버의 처리 용량(가중치)과 현재 활성 연결 수를 모두 고려한다.

• 수식적 표현: 각 서버 S_i의 현재 활성 연결 수 C_i를 해당 서버의 가중치 W_i로 나눈 값, 즉 정규화된 부하(C_i / W_i)가 가장 작은 서버를 선택한다.

코드 스니펫

$S_{target} = \underset{S_i \in \{S_1,..., S_N\}}{\arg\min} \frac{C_i}{W_i}$

• 적합한 환경: 서버 사양이 다르고, 동시에 세션 유지 시간이나 요청 처리 시간도 불균일한 복잡한 환경에서 가장 정교하게 부하를 분산할 수 있다.

3.2.5 IP 해시 (IP Hash)

• 원리: 클라이언트의 출발지 IP 주소를 해시 함수(hash function)에 입력하여 나온 결과값을 기반으로 요청을 보낼 서버를 결정한다.11 해시 함수의 특성상 동일한 IP 주소는 항상 동일한 해시 결과를 반환하므로, 특정 클라이언트의 요청은 항상 같은 서버로 전달된다.42

• 수식적 표현: TargetServerIndex = Hash(ClientIP) % N 여기서 N은 서버의 총 개수이다.

• 주요 용도: 이 방식의 주 목적은 부하 분산 자체보다는 세션 지속성(Session Persistence)을 보장하는 것이다. 사용자의 로그인 정보나 장바구니 데이터를 특정 서버에 저장해야 할 때 유용하다.14

IP 해시 알고리즘은 세션 지속성을 간단하게 구현할 수 있는 방법이지만, 특정 네트워크 환경에서는 심각한 트래픽 불균형을 초래할 수 있다. 예를 들어, 대규모 기업이나 교육 기관의 사용자들이 프록시 서버나 NAT(Network Address Translation) 게이트웨이를 통해 인터넷에 접속하는 경우, 로드 밸런서 관점에서는 수많은 사용자가 모두 동일한 단일 공인 IP 주소에서 오는 것처럼 보인다.2 이 경우, 해시 함수의 입력값이 동일하므로 모든 요청이 단 하나의 백엔드 서버로 집중되는 ‘핫스팟(hot spot)’ 현상이 발생한다. 이는 부하 분산이라는 로드 밸런서의 근본적인 목적을 완전히 위배하는 결과를 낳는다. 따라서 IP 해시 알고리즘은 클라이언트 IP의 분포가 비교적 균일하다고 보장되는 환경에서만 제한적으로 사용해야 하며, 이러한 제약 때문에 현대 웹 애플리케이션에서는 쿠키 기반의 세션 지속성 방식이 더 선호된다.

3.2.6 최소 응답 시간 (Least Response Time)

• 원리: 가장 지능적인 동적 알고리즘 중 하나로, 서버의 현재 활성 연결 수뿐만 아니라 서버가 요청에 응답하는 데 걸리는 평균 시간(response time)까지 함께 고려한다.9 로드 밸런서는 이 두 지표를 종합하여 현재 가장 빠르게 응답할 것으로 예상되는 서버에 요청을 보낸다.44

• 수식적 표현: 각 서버 S_i의 평균 응답 시간을 R_i, 활성 연결 수를 C_i라고 할 때, 로드 밸런서는 f(R_i, C_i) 값을 계산하여 이 값이 가장 작은 서버를 선택한다. NetScaler와 같은 일부 시스템에서는 이 값을 N = C_i * R_i (Number of Active Transactions * Time to First Byte)로 계산한다.45

• 적합한 환경: 사용자에게 가장 빠른 응답 시간을 제공하는 것이 최우선 과제인 고성능 서비스에 적합하다. 하지만 응답 시간을 지속적으로 측정하고 계산해야 하므로 로드 밸런서의 부하가 가장 크다.

3.3 핵심 요약: 로드 밸런싱 알고리즘 비교

각 알고리즘의 특성을 종합적으로 비교하면 다음과 같다. 이 표는 아키텍트가 특정 워크로드에 가장 적합한 알고리즘을 선택하는 데 유용한 의사결정 도구가 될 수 있다.

4. 로드 밸런서의 분류와 선택 기준

로드 밸런서는 동작하는 네트워크 계층, 구현 방식 등 다양한 기준에 따라 분류될 수 있다. 이러한 분류를 이해하는 것은 특정 시스템 아키텍처에 가장 적합한 로드 밸런서를 선택하기 위한 필수적인 과정이다. 특히 OSI 7계층 모델에 기반한 L4와 L7 로드 밸런서의 구분, 그리고 물리적 장비와 소프트웨어 솔루션 간의 차이는 가장 중요한 선택 기준이 된다.

4.1 OSI 계층별 분류: L4 vs. L7 로드 밸런서

로드 밸런서는 OSI 7계층 모델 중 어느 계층의 정보를 활용하여 트래픽을 분산하는지에 따라 L4와 L7 로드 밸런서로 나뉜다. L4부터 포트(Port) 정보를 다룰 수 있기 때문에, 이 두 유형이 가장 널리 사용된다.46

4.1.1 L4 로드 밸런서 (네트워크 로드 밸런서)

• 동작 원리: OSI 4계층인 전송 계층(Transport Layer)에서 동작한다. 패킷의 헤더에 있는 정보, 즉 출발지/목적지 IP 주소와 TCP/UDP 포트 번호를 기반으로 스위칭을 수행한다.5 L4 로드 밸런서는 패킷의 내용(데이터 페이로드)을 들여다보지 않고 단순히 적절한 서버로 전달(forward)하는 역할만 한다.9

• 장점:

• 고속 처리: 패킷 페이로드를 분석할 필요가 없으므로 데이터 처리 속도가 매우 빠르고 효율적이다.9

• 프로토콜 독립성: TCP, UDP 등 특정 애플리케이션 프로토콜에 종속되지 않고 다양한 종류의 트래픽을 처리할 수 있다.

• 보안 단순성: 암호화된 트래픽(예: HTTPS)을 복호화하지 않고 그대로 통과시키므로, 로드 밸런서에 SSL 인증서를 관리할 필요가 없고 종단 간 암호화를 유지할 수 있다.9

• 단점:

• 제한된 라우팅: 패킷의 내용을 볼 수 없으므로, URL 경로, HTTP 헤더, 쿠키 값 등 애플리케이션 레벨의 정보를 이용한 정교한 라우팅이 불가능하다.9

• 세션 지속성 한계: 주로 IP 해시 방식에 의존하므로, 앞서 언급된 NAT 환경에서의 트래픽 쏠림 문제에 취약하다.2

4.1.2 L7 로드 밸런서 (애플리케이션 로드 밸런서)

• 동작 원리: OSI 7계층인 애플리케이션 계층(Application Layer)에서 동작한다. L4 로드 밸런서의 모든 기능을 포함하며, 추가적으로 HTTP/HTTPS와 같은 애플리케이션 프로토콜의 페이로드 내용을 분석하여 분산 처리를 수행한다.4 URL 경로, 호스트 헤더, HTTP 메서드, 쿠키, 쿼리 문자열 등 다양한 정보를 라우팅 결정에 활용할 수 있다.5

• 장점:

• 정교한 라우팅: 콘텐츠 기반의 지능적인 라우팅이 가능하다. 예를 들어, /images 경로의 요청은 이미지 캐싱 서버로, /api 경로의 요청은 API 처리 서버로, 그 외의 요청은 일반 웹 서버로 보내는 등의 세밀한 제어가 가능하다.4

• 고급 기능 제공: SSL 오프로딩(Termination), 쿠키 기반 세션 지속성, 캐싱, 압축 등 다양한 고급 기능을 제공하여 백엔드 서버의 부하를 줄이고 성능을 최적화할 수 있다.9

• 보안 강화: 트래픽의 내용을 검사할 수 있으므로, SQL 인젝션이나 크로스 사이트 스크립팅(XSS)과 같은 웹 공격을 탐지하는 웹 애플리케이션 방화벽(WAF) 기능을 통합하거나, 특정 패턴을 가진 바이러스나 DDoS 공격 트래픽을 필터링하는 데 활용될 수 있다.30

• 단점:

• 성능 부하: 패킷 내용을 분석하고, 필요시 암호화된 트래픽을 복호화하는 과정에서 L4 로드 밸런서보다 더 많은 CPU와 메모리 자원을 소모한다. 이로 인해 처리 속도가 상대적으로 느리고 지연 시간이 증가할 수 있다.46

• 비용: 더 복잡한 기능을 수행하므로 일반적으로 L4 로드 밸런서보다 가격이 비싸다.9

L4와 L7 로드 밸런서의 선택은 단순히 ’성능’과 ‘기능’ 간의 트레이드오프를 넘어, 전체 시스템의 ’보안 경계(Security Boundary)’를 어디에 설정할 것인가에 대한 근본적인 아키텍처 결정과 직결된다. L7 로드 밸런서가 SSL Termination을 수행하면, 암호화된 HTTPS 트래픽은 로드 밸런서에서 평문 HTTP로 변환된 후 내부 서버로 전달된다.52 이 경우 보안 경계는 로드 밸런서가 되며, 모든 SSL 인증서 관리가 중앙 집중화되어 운영 편의성은 높아지지만, 로드 밸런서와 백엔드 서버 간 내부 네트워크 구간은 암호화되지 않아 보안에 취약해질 수 있다.54 반면, L4 로드 밸런서는 SSL 트래픽을 그대로 통과(Passthrough)시키고 각 백엔드 서버가 직접 암복호화를 처리한다.52 이 구조에서는 클라이언트부터 백엔드 서버까지 종단 간 암호화(End-to-End Encryption)가 유지되어 보안성은 높지만, 모든 서버에 개별적으로 인증서를 배포하고 관리해야 하므로 운영 복잡성이 증가한다. 따라서 이 선택은 기술적 특성뿐만 아니라 조직의 보안 정책과 운영 모델까지 고려해야 하는 중요한 결정이다.

4.2 구현 방식별 분류: 하드웨어 vs. 소프트웨어

로드 밸런서는 전용 물리 장비로 제공되거나, 범용 서버에 설치되는 소프트웨어 형태로 제공될 수 있다.

4.2.1 하드웨어 로드 밸런서 (Hardware Load Balancer)

• 개념: 로드 밸런싱을 위해 특별히 설계되고 최적화된 전용 물리 장비이다. ADC(Application Delivery Controller)라고도 불리며, F5 Networks의 BIG-IP, Citrix의 NetScaler 등이 대표적인 제품이다.6

• 장점: ASIC(주문형 반도체) 등 특화된 하드웨어를 사용하여 매우 높은 수준의 성능, 처리량, 안정성을 제공한다.14 수 기가바이트에 달하는 대규모 트래픽을 안정적으로 처리할 수 있다.8

• 단점: 초기 도입 비용이 매우 높고, 물리적인 설치 공간을 필요로 한다. 트래픽 증가에 맞춰 장비를 교체하거나 추가해야 하므로 확장성이 비유연하며, 특정 벤더 기술에 종속될 위험이 있다.8

4.2.2 소프트웨어 로드 밸런서 (Software Load Balancer)

• 개념: 일반적인 서버, 가상 머신(VM), 컨테이너 환경에 설치하여 사용하는 소프트웨어 애플리케이션이다.11 오픈소스 솔루션인 Nginx, HAProxy가 널리 사용되며, 클라우드 환경에서 제공되는 관리형 로드 밸런서(예: AWS ELB)도 이 범주에 속한다.14

• 장점:

• 비용 효율성: 하드웨어에 비해 초기 도입 비용이 매우 낮거나 없으며(오픈소스의 경우), 필요한 만큼만 자원을 할당하여 사용할 수 있다.8

• 유연성 및 확장성: 가상화 및 클라우드 환경에 최적화되어 있어, 트래픽 변화에 따라 손쉽게 인스턴스를 추가(Scale-out)하거나 제거할 수 있다.8

• 다양한 환경 지원: 베어메탈, 가상 머신, 컨테이너, 클라우드 등 다양한 인프라 환경에 배포할 수 있다.57

• 단점: 단일 인스턴스의 성능은 일반적으로 전용 하드웨어 장비보다 낮을 수 있다. 또한 소프트웨어의 설치, 구성, 유지보수 및 보안 관리에 대한 책임이 사용자에게 있다.

4.3 핵심 요약: L4 vs. L7 로드 밸런서 선택 가이드

5. 고가용성(High Availability) 아키텍처와 로드 밸런서

로드 밸런서는 백엔드 서버의 장애로부터 서비스를 보호하는 핵심 역할을 하지만, 로드 밸런서 자체가 장애를 일으키면 전체 서비스가 중단되는 단일 장애점(SPOF)이 될 수 있다.21 따라서 진정한 고가용성을 달성하기 위해서는 로드 밸런서 자체를 이중화하여 안정성을 확보해야 한다.10 이를 위한 대표적인 구성 방식으로는 Active-Standby와 Active-Active가 있으며, 이들 구성의 자동 장애 조치(Failover)를 위해 VRRP와 같은 프로토콜이 사용된다.

5.1 로드 밸런서 이중화 구성 방식 비교

로드 밸런서 이중화는 동일한 기능을 수행하는 두 대 이상의 로드 밸런서를 배치하여 한 장비에 문제가 발생하더라도 다른 장비가 즉시 서비스를 이어받을 수 있도록 구성하는 것을 의미한다.58

5.1.1 Active-Standby (Active-Passive)

• 동작 원리: 이중화된 로드 밸런서 중 한 대(Active)만이 실제 서비스 트래픽을 처리하고, 다른 한 대(Standby 또는 Passive)는 대기 상태에 있는 구성이다.59 Standby 장비는 주기적으로 Active 장비의 상태를 확인(Health Check)하며, Active 장비에서 장애가 감지되면 즉시 그 역할을 인계받아(Failover) 서비스의 연속성을 보장한다.34

• 장점:

• 구성 및 동작 방식이 비교적 단순하고 직관적이다.

• 장애 발생 시 서비스 전환 과정이 명확하여 문제 해결이 용이하다.

• 단점:

• Standby 장비는 장애 발생 시에만 동작하므로 평상시에는 유휴 상태로 존재한다. 이는 컴퓨팅 자원의 낭비로 이어질 수 있다.60

• Failover가 발생하는 순간, 아주 짧은 시간 동안 서비스 순단이 발생할 수 있다.

5.1.2 Active-Active

• 동작 원리: 이중화된 두 대 이상의 로드 밸런서가 모두 동시에 활성 상태로 실제 서비스 트래픽을 분담하여 처리하는 구성이다.59 각 로드 밸런서는 전체 트래픽의 일부를 처리하며, DNS 라운드 로빈이나 BGP Anycast와 같은 기술을 사용하여 외부 트래픽을 여러 로드 밸런서로 분산시킨다.

• 장점:

• 모든 장비의 자원을 항상 활용하므로 전체 시스템의 처리 용량(Throughput)이 증가하고 자원 효율성이 높다.60

• 한 장비에 장애가 발생하더라도 나머지 활성 장비들이 즉시 해당 트래픽을 흡수하므로 서비스 중단 시간이 거의 없다 (Downtime-free).60

• 단점:

• 두 장비가 동시에 동작하므로 구성이 Active-Standby 방식보다 복잡하다.

• 특히 세션 지속성(Session Persistence)과 같은 상태 정보를 유지해야 하는 경우, 활성 로드 밸런서들 간에 상태 정보를 실시간으로 동기화하는 메커니즘이 필요하며, 이는 새로운 복잡성과 성능 병목 지점을 야기할 수 있다.

Active-Active 구성은 이론적으로 우수하지만, 상태(State)를 다루는 애플리케이션에서는 구현의 복잡성이 기하급수적으로 증가한다. 예를 들어, IP 해시 방식으로 세션 지속성을 구현한 경우, 클라이언트의 요청이 DNS 라운드 로빈에 의해 서로 다른 Active 로드 밸런서로 유입되면, 동일한 클라이언트 IP라도 다른 백엔드 서버로 라우팅되어 세션이 유실될 수 있다. 이를 해결하기 위해 로드 밸런서 간 세션 테이블을 동기화해야 하는데, 이 동기화 과정 자체가 시스템의 복잡도를 높이고 새로운 장애 지점이 될 수 있다. 따라서 상태가 없는(Stateless) 애플리케이션이나 정교한 상태 동기화 메커니즘이 설계된 경우가 아니라면, 대부분의 상태 기반(Stateful) 애플리케이션에서는 구현이 단순하고 동작이 예측 가능한 Active-Standby 구성이 더 안정적인 선택일 수 있다.

5.2 VRRP(Virtual Router Redundancy Protocol)를 이용한 자동 절체

VRRP는 로드 밸런서 이중화, 특히 Active-Standby 구성에서 자동 장애 조치(Failover)를 구현하기 위해 널리 사용되는 표준 프로토콜이다.63

• 개념: 여러 개의 물리적 라우터(또는 로드 밸런서)를 하나의 논리적인 가상 라우터 그룹으로 묶고, 이 그룹에 단일 가상 IP(VIP)와 가상 MAC 주소를 할당한다.65 클라이언트는 이 VIP를 목적지로 통신하며, 실제 어떤 물리적 장비가 요청을 처리하는지는 인지하지 못한다.67

• 동작 메커니즘:

1. Master/Backup 선출: VRRP 그룹 내에서 각 장비는 우선순위(Priority) 값을 가진다 (0-255, 기본값 100). 가장 높은 우선순위를 가진 장비가 Master로 선출되어 VIP에 대한 소유권을 갖고 모든 트래픽을 처리한다. 나머지 장비들은 Backup 상태로 대기한다.64 우선순위가 동일할 경우, 더 높은 IP 주소를 가진 장비가 Master가 된다.64

2. 상태 감시 (Advertisement): Master 장비는 자신의 상태가 정상임을 알리기 위해 주기적으로(기본 1초) ‘VRRP Advertisement’ 메시지를 VRRP 전용 멀티캐스트 주소인 224.0.0.18로 전송한다.65 Backup 장비들은 이 메시지를 수신하며 Master의 상태를 감시한다.

3. 장애 조치 (Failover): Backup 장비가 설정된 시간(Master Down Interval, 기본 약 3초) 동안 Master로부터 Advertisement 메시지를 수신하지 못하면, Master에 장애가 발생했다고 판단한다.65 이때 가장 높은 우선순위를 가진 Backup 장비가 스스로를 Master로 전환하고, 해당 VIP의 소유권을 가져온다. 새로운 Master는 GARP(Gratuitous ARP) 패킷을 네트워크에 브로드캐스트하여, 동일 네트워크상의 다른 장비들(예: 스위치)에게 이제부터 해당 VIP는 자신의 MAC 주소와 연결된다는 사실을 알려 ARP 테이블을 갱신하도록 한다.65 이 과정을 통해 트래픽은 중단 없이 새로운 Master 장비로 흐르게 된다.

6. 고급 기능 및 최적화 전략

현대의 로드 밸런서는 단순한 트래픽 분산을 넘어 애플리케이션의 성능과 사용자 경험을 최적화하기 위한 다양한 고급 기능을 제공한다. 그중에서도 사용자의 세션 상태를 일관되게 유지하는 ’세션 지속성’과 암호화 처리 부담을 줄여주는 ’SSL 오프로딩’은 가장 핵심적인 최적화 전략이다.

6.1 세션 지속성 (Session Persistence, Sticky Session)

• 개념과 필요성: HTTP 프로토콜은 본질적으로 상태가 없는(Stateless) 프로토콜이다. 즉, 각 요청은 이전 요청과 독립적으로 처리된다. 하지만 현대 웹 애플리케이션의 대부분은 사용자의 로그인 상태, 장바구니 내용, 개인화 설정 등 연속적인 상호작용을 위해 세션(Session) 정보를 서버 측에 저장해야 한다.68 로드 밸런싱 환경에서는 사용자의 연속된 요청이 서로 다른 백엔드 서버로 분산될 수 있는데, 이 경우 첫 번째 요청을 처리한 서버에 저장된 세션 정보에 두 번째 요청을 처리하는 서버가 접근할 수 없어 세션이 유실되는 문제가 발생한다.70 예를 들어, 서버 A에서 로그인한 후 다음 페이지 요청이 서버 B로 전달되면, 서버 B는 로그인 정보를 알지 못하므로 사용자에게 다시 로그인을 요구하게 된다.70

세션 지속성(Session Persistence), 또는 스티키 세션(Sticky Session)은 이러한 문제를 해결하기 위해 특정 클라이언트로부터의 모든 요청을 해당 세션이 유지되는 동안에는 항상 동일한 백엔드 서버로 전달하도록 보장하는 기술이다.14

• 구현 방식:

• 쿠키 기반 (Cookie-based Persistence): 가장 널리 사용되고 유연한 방식이다. 로드 밸런서는 클라이언트의 첫 요청에 대한 응답을 보낼 때, 자신이 할당한 백엔드 서버를 식별할 수 있는 정보(예: 서버 ID)를 담은 쿠키를 삽입한다.71 클라이언트의 웹 브라우저는 이 쿠키를 저장했다가 이후 모든 요청에 포함시켜 전송한다. 로드 밸런서는 요청에 포함된 쿠키 값을 확인하여 해당 요청을 지정된 서버로 정확하게 라우팅한다.74 이 방식은 클라이언트의 IP 주소가 변경되더라도 세션을 유지할 수 있는 장점이 있다.

• IP 해시 기반 (Source IP Hash Persistence): 제2장에서 설명한 IP 해시 알고리즘을 사용하여 클라이언트의 출발지 IP 주소를 기반으로 서버를 고정 할당하는 방식이다.75 구현이 간단하지만, NAT 환경이나 모바일 네트워크에서 다수의 사용자가 동일한 공인 IP를 공유할 경우 트래픽이 특정 서버에 집중되는 심각한 불균형을 초래할 수 있다.75

• 세션 클러스터링(Session Clustering)과의 비교:

세션 불일치 문제를 해결하는 또 다른 접근법은 세션 클러스터링이다. 두 기술은 근본적인 철학에서 차이가 있다.

• 스티키 세션: 클라이언트를 특정 서버에 ’고정’시키는 방식이다. 구현이 비교적 간단하지만, 고정된 서버에 장애가 발생하면 해당 서버에 저장된 모든 세션 정보가 유실되는 단점이 있다.75

• 세션 클러스터링: 여러 백엔드 서버 간에 세션 데이터를 실시간으로 복제하거나 외부의 중앙 집중식 세션 스토어(예: Redis, Memcached)를 통해 공유하는 방식이다.75 이 방식은 특정 서버에 장애가 발생하더라도 다른 서버가 세션 정보를 가지고 있으므로 서비스 중단 없이 세션을 이어갈 수 있어 가용성이 훨씬 높다. 하지만 모든 서버 간에 세션 데이터를 동기화하는 데 따른 네트워크 오버헤드가 발생하며, 아키텍처 구현이 복잡하다는 단점이 있다.75

6.2 SSL 오프로딩 (SSL Offloading)

• 개념과 원리: SSL/TLS 프로토콜을 이용한 데이터 암호화 및 복호화 과정은 상당한 CPU 연산을 필요로 한다.54 백엔드 서버가 모든 클라이언트 요청에 대해 이 작업을 수행하면, 정작 중요한 애플리케이션 비즈니스 로직을 처리할 컴퓨팅 자원이 줄어들어 전체적인 성능 저하를 유발할 수 있다.53

SSL 오프로딩(SSL Offloading)은 이러한 암복호화 연산의 부담을 백엔드 서버로부터 ‘덜어내어(offload)’ 로드 밸런서가 대신 처리하도록 하는 기술이다.12 클라이언트로부터 들어오는 암호화된 HTTPS 트래픽을 로드 밸런서가 받아서 복호화한 후, 암호화되지 않은 평문 HTTP 트래픽으로 변환하여 내부 백엔드 서버에 전달한다. 이를 통해 백엔드 서버는 암복호화 작업 없이 애플리케이션 로직 처리에만 집중할 수 있게 되어 서버의 부하가 줄고 전체 시스템의 성능과 처리량이 향상된다.2

• 처리 방식 비교:

SSL 트래픽을 처리하는 방식은 보안 요구사항과 아키텍처에 따라 세 가지로 나눌 수 있다.

• SSL Termination: 가장 일반적인 SSL 오프로딩 방식으로, ’SSL 종료’라고도 한다. 클라이언트와 로드 밸런서 사이의 구간은 암호화된 HTTPS로 통신하고, 로드 밸런서가 SSL 연결을 종료(terminate)한 후, 로드 밸런서와 백엔드 서버 사이의 내부 네트워크 구간은 암호화되지 않은 평문 HTTP로 통신한다.52 이 방식은 서버 부하 감소 효과가 가장 크고, 모든 SSL 인증서를 로드 밸런서 한 곳에서 중앙 집중적으로 관리할 수 있어 운영이 편리하다는 장점이 있다.54 하지만 내부망 구간의 트래픽이 암호화되지 않으므로, 이 구간에서 데이터가 탈취될 경우 보안에 취약하다는 명백한 단점이 있다.52

• SSL Passthrough: 로드 밸런서가 SSL 트래픽의 암복호화에 전혀 관여하지 않고, 암호화된 TCP 패킷을 그대로 백엔드 서버로 전달(pass through)하는 방식이다.52 이 경우, SSL 핸드셰이크와 암복호화는 클라이언트와 백엔드 서버 간에 직접 이루어지므로, 클라이언트부터 서버까지 전 구간에 걸쳐 종단 간 암호화(End-to-End Encryption)가 보장된다.52 보안성이 가장 높지만, SSL 오프로딩의 성능 향상 이점을 전혀 얻을 수 없으며, 모든 백엔드 서버에 개별적으로 SSL 인증서를 설치하고 관리해야 하는 운영상의 부담이 있다.

• SSL Bridging: Termination과 Passthrough의 장점을 결합한 방식이다. 클라이언트로부터 온 HTTPS 트래픽을 로드 밸런서에서 일단 복호화한다. 이를 통해 L7 로드 밸런서는 트래픽의 내용을 검사하여 정교한 라우팅을 수행하거나 WAF 정책을 적용할 수 있다. 그 후, 로드 밸런서는 이 트래픽을 다시 암호화하여 백엔드 서버로 전달한다.52 즉, 클라이언트-로드밸런서 구간과 로드밸런서-서버 구간에 각각 별도의 SSL 연결(다리, bridge)이 생성된다. 이 방식은 높은 수준의 보안과 L7 기능 활용을 동시에 만족시킬 수 있지만, 로드 밸런서와 모든 백엔드 서버 양쪽에 인증서를 관리해야 하고, 암복호화가 두 번 발생하여 시스템 전체에 상당한 부하를 줄 수 있다.52

6.3 핵심 요약: SSL 처리 방식 비교

7. 주요 클라우드 플랫폼의 로드 밸런싱 서비스 비교 분석

클라우드 컴퓨팅의 확산과 함께, 주요 클라우드 제공업체(CSP)들은 각자의 아키텍처 철학을 반영한 고도로 관리되는 로드 밸런싱 서비스를 제공하고 있다. Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure는 각각 독자적인 로드 밸런서 포트폴리오를 통해 다양한 고객 요구사항에 대응하고 있다. 이들 서비스를 비교 분석하는 것은 특정 클라우드 환경에 최적화된 아키텍처를 설계하는 데 필수적이다.

7.1 Amazon Web Services (AWS): Elastic Load Balancing (ELB)

AWS의 ELB는 기능과 동작 계층에 따라 명확하게 분리된 여러 유형의 로드 밸런서를 제공하는 모듈식 접근 방식을 취한다.82

• Application Load Balancer (ALB): OSI 7계층에서 동작하는 대표적인 L7 로드 밸런서다.83 HTTP/HTTPS 트래픽 처리에 특화되어 있으며, URL 경로, 호스트 이름, HTTP 헤더, 쿼리 문자열 등 다양한 조건에 기반한 정교한 요청 라우팅 규칙을 설정할 수 있다.85 마이크로서비스 아키텍처나 컨테이너 기반 애플리케이션(Amazon ECS, EKS) 환경에서 서비스별로 트래픽을 분기하는 데 매우 효과적이다.4

• Network Load Balancer (NLB): OSI 4계층에서 동작하는 고성능 L4 로드 밸런서다.83 TCP, UDP, TLS 프로토콜 트래픽을 처리하며, 초당 수백만 건의 요청을 매우 낮은 지연 시간으로 처리할 수 있도록 설계되었다.4 NLB는 고정 IP(Elastic IP)를 할당할 수 있어, IP 주소 기반의 화이트리스팅이 필요한 경우나 외부 시스템과의 연동에 유리하다.85

• Gateway Load Balancer (GWLB): OSI 3계층(네트워크 계층) 및 4계층에서 동작하는 특수 목적의 로드 밸런서다.85 방화벽, 침입 탐지 및 방지 시스템(IDS/IPS) 등 타사(3rd-party)의 가상 네트워크 어플라이언스를 VPC 트래픽 경로에 투명하게 삽입하고, 이들 어플라이언스 자체를 부하 분산 및 확장할 수 있도록 지원한다.85

• Classic Load Balancer (CLB): AWS의 1세대 로드 밸런서로, L4와 L7 기능을 모두 제공했지만 현재는 기능적으로 ALB와 NLB로 대체되었으며 신규 사용은 권장되지 않는다.82

7.2 Google Cloud Platform (GCP): Cloud Load Balancing

GCP의 로드 밸런싱 서비스는 강력한 글로벌 네트워크를 기반으로 ’전역(Global)’과 ’리전(Regional)’이라는 지리적 범위를 기준으로 서비스를 구분하는 것이 가장 큰 특징이다.88

• Application Load Balancer (외부/내부): L7 로드 밸런서로, 외부 및 내부용으로 나뉜다.

• 외부 애플리케이션 부하 분산기: GCP의 가장 대표적인 서비스로, 전역 Anycast IP 주소를 사용하여 단일 IP로 전 세계에 분산된 백엔드에 트래픽을 라우팅한다.90 사용자 요청은 지리적으로 가장 가까운 Google 네트워크 엣지(Edge)에서 처리되어 낮은 지연 시간을 제공한다. Cloud CDN(콘텐츠 전송 네트워크) 및 Google Cloud Armor(WAF 및 DDoS 방어)와 긴밀하게 통합되어 있다.90

• 내부 애플리케이션 부하 분산기: VPC 네트워크 내의 내부 트래픽을 위한 L7 프록시 기반 로드 밸런서다.89

• Network Load Balancer (프록시/패스스루): L4 로드 밸런서로, 동작 방식에 따라 두 종류로 나뉜다.

• 프록시 네트워크 부하 분산기: TCP 트래픽을 위한 L4 리버스 프록시로, SSL 오프로딩 기능을 제공한다. 외부용은 전역, 내부용은 리전 단위로 구성된다.90

• 패스스루 네트워크 부하 분산기: 고성능의 비프록시(non-proxied) 로드 밸런서다. 실제 클라이언트의 IP 주소를 백엔드에 그대로 전달(pass-through)하며, TCP, UDP 외에도 ESP, GRE, ICMP 등 다양한 IP 프로토콜을 지원한다.89

7.3 Microsoft Azure: Azure Load Balancer

Azure는 기본적인 L4 로드 밸런싱과 고급 L7 로드 밸런싱 기능을 별도의 서비스로 명확히 구분하여 제공한다. 이는 기존 엔터프라이즈 네트워크 아키텍처와 유사한 접근 방식이다.

• Azure Load Balancer: OSI 4계층에서 동작하는 L4 로드 밸런서다.93 5-튜플(출발지 IP, 출발지 포트, 목적지 IP, 목적지 포트, 프로토콜) 해시를 기반으로 트래픽을 분산한다.93 공용(Public)과 내부(Internal) 로드 밸런서로 나뉘며, 제공되는 기능과 SLA 수준에 따라 Basic, Standard, Gateway의 세 가지 SKU(Stock Keeping Unit)로 구분된다.95

• Application Gateway: 웹 트래픽에 특화된 L7 로드 밸런서로, ADC(Application Delivery Controller)로서의 기능을 제공한다.97 URL 경로 기반 라우팅, 다중 사이트 호스팅, SSL 오프로딩, 세션 어피니티(Session Affinity), 그리고 통합 웹 애플리케이션 방화벽(WAF)과 같은 고급 기능을 포함한다.98

• Azure Front Door: GCP의 외부 애플리케이션 부하 분산기와 유사한 전역(Global) L7 로드 밸런싱 및 사이트 가속 서비스다.97 Anycast 프로토콜을 사용하여 전 세계 사용자 트래픽을 가장 가까운 Azure PoP(Point of Presence)로 라우팅하고, 글로벌 장애 조치 및 CDN 캐싱 기능을 제공한다.

각 클라우드 제공업체의 로드 밸런서 포트폴리오는 해당 기업의 근본적인 네트워크 아키텍처 철학을 반영한다. GCP는 강력한 글로벌 네트워크를 기반으로 ‘전역’ 리소스를 기본으로 제공하여 글로벌 서비스 배포를 단순화한다.90 반면 AWS는 ’리전’과 ’가용 영역(AZ)’이라는 강력한 격리 단위를 기반으로 서비스를 모듈화하여 제공하며, 글로벌 로드 밸런싱을 위해서는 Route 53이나 Global Accelerator 같은 별도의 서비스를 조합해야 한다.101 Azure는 전통적인 엔터프라이즈 네트워크 환경과의 친숙성을 고려하여, 기본적인 L4 기능과 고급 L7 ‘게이트웨이’ 기능을 명확히 분리하는 경향을 보인다.97 따라서 클라우드 로드 밸런서의 선택은 단순히 기능 목록을 비교하는 것을 넘어, 각 클라우드의 아키텍처 철학이 자신의 애플리케이션 배포 전략과 얼마나 부합하는지를 평가하는 과정이 되어야 한다.

7.4 핵심 요약: AWS vs. GCP vs. Azure 로드 밸런서 비교

8. 결론: 최적의 로드 밸런서 선택을 위한 종합 가이드

로드 밸런서는 현대 분산 시스템의 성공을 좌우하는 핵심 기술이다. 본 안내서는 로드 밸런서의 근본적인 필요성부터 시작하여, 그 작동 원리, 다양한 알고리즘, 계층 및 구현 방식에 따른 분류, 고가용성 구성, 그리고 고급 최적화 전략에 이르기까지 다각적인 측면을 심층적으로 분석하였다. 또한, 주요 클라우드 플랫폼들이 제공하는 서비스의 특징과 그 기저에 깔린 아키텍처 철학을 비교함으로써, 이론과 실제를 아우르는 포괄적인 시각을 제공하고자 하였다.

8.1 의사결정 프레임워크

최적의 로드 밸런서를 선택하는 것은 단일 정답이 없는 복합적인 문제이며, 시스템의 요구사항과 제약조건을 종합적으로 고려하는 체계적인 접근이 필요하다. 다음은 합리적인 의사결정을 위한 프레임워크이다.

1. 애플리케이션 특성 분석 (L4 vs. L7):

• 질문: 처리해야 할 트래픽이 단순 TCP/UDP 스트림인가, 아니면 복잡한 HTTP/HTTPS 요청인가? URL 경로, 헤더, 쿠키 등 애플리케이션 계층의 정보를 기반으로 한 정교한 라우팅이 필요한가?

• 결정: 단순 TCP/UDP 트래픽이거나 최고 수준의 성능이 필요하다면 L4 로드 밸런서를 우선 고려한다.103 웹 애플리케이션, API 게이트웨이, 마이크로서비스와 같이 콘텐츠 기반 라우팅이 필요하다면

L7 로드 밸런서가 필수적이다.104

2. 성능 및 확장성 요구사항 평가 (H/W vs. S/W vs. Cloud):

• 질문: 예측 가능하고 지속적인 고성능 트래픽을 처리해야 하는가, 아니면 트래픽 변동이 심하고 탄력적인 확장이 중요한가?

• 결정: 수십 Gbps 이상의 예측 가능한 대규모 트래픽을 처리해야 한다면 하드웨어 로드 밸런서가 적합할 수 있다.8 반면, 유연한 확장성, 비용 효율성, 클라우드 네이티브 환경과의 통합이 중요하다면

소프트웨어 또는 클라우드 관리형 로드 밸런서가 합리적인 선택이다.8

3. 보안 요구사항 정의 (SSL 처리 및 WAF):

• 질문: 종단 간 암호화가 법적 또는 규제적 요구사항인가? 웹 애플리케이션 방화벽(WAF) 통합이 필요한가? 인증서 관리를 중앙에서 처리할 것인가, 각 서버에서 분산 처리할 것인가?

• 결정: 최고 수준의 보안을 위해 종단 간 암호화가 필수라면 SSL Passthrough가 가능한 L4 로드 밸런서를 고려해야 한다. 중앙 집중식 인증서 관리와 WAF 통합이 필요하다면 SSL 오프로딩 기능이 있는 L7 로드 밸런서를 선택해야 한다.52

4. 가용성 및 운영 모델 수립 (이중화 및 관리 주체):

• 질문: 어느 정도의 다운타임을 허용할 수 있는가? Active-Active 구성을 통해 성능 향상과 자원 효율성을 극대화할 것인가, 아니면 Active-Standby 구성으로 안정성과 단순성을 우선할 것인가? 인프라 관리 부담을 내부에서 질 것인가, 클라우드 제공업체에 위임할 것인가?

• 결정: 서비스의 중요도에 따라 이중화 방식을 선택하고, 조직의 운영 역량과 비용 구조를 고려하여 온프레미스(하드웨어/소프트웨어) 또는 클라우드 관리형 서비스를 결정한다.

8.2 미래 기술 동향 및 전망

로드 밸런싱 기술은 컴퓨팅 패러다임의 변화와 함께 끊임없이 진화하고 있다. 앞으로의 로드 밸런서는 다음과 같은 방향으로 발전할 것으로 전망된다.

• 서비스 메시 (Service Mesh): 마이크로서비스 아키텍처가 보편화되면서, 외부 트래픽(North-South)을 처리하는 전통적인 게이트웨이 로드 밸런서의 역할을 넘어, 서비스 간 내부 통신(East-West)을 제어하는 서비스 메시 기술의 중요성이 커지고 있다. Istio, Linkerd와 같은 서비스 메시는 사이드카 프록시(Sidecar Proxy, 예: Envoy)를 통해 각 마이크로서비스 레벨에서 정교한 로드 밸런싱, 트래픽 제어, 보안 및 관측 가능성을 제공한다.63 이는 로드 밸런싱의 책임이 중앙 집중식 게이트웨이에서 분산된 데이터 플레인으로 이동하고 있음을 시사한다.

• AI/ML 기반 지능형 로드 밸런싱: 과거의 트래픽 패턴, 서버의 리소스 사용률, 응답 시간 등 방대한 데이터를 머신러닝 모델로 학습하여 미래의 부하를 예측하고, 이를 기반으로 트래픽을 선제적으로 분산하는 지능형 로드 밸런싱 기술이 부상할 것이다. 이는 단순한 현재 상태 기반의 동적 로드 밸런싱을 넘어, 예측 기반의 최적화된 트래픽 관리를 가능하게 할 것이다.

• 엣지 컴퓨팅과 엣지 로드 밸런싱: 5G, IoT의 확산으로 데이터가 생성되고 소비되는 위치가 사용자에게 더 가까운 ’엣지(Edge)’로 이동하고 있다. 이에 따라, 중앙 데이터 센터가 아닌 여러 엣지 로케이션에서 로드 밸런싱을 수행하여 지연 시간을 최소화하고 사용자 경험을 극대화하는 엣지 로드 밸런서의 역할이 더욱 중요해질 것이다.

결론적으로, 로드 밸런서는 시스템 아키텍처의 단순한 구성 요소를 넘어, 애플리케이션의 성능, 안정성, 보안을 결정하는 전략적 자산이다. 아키텍트는 본 안내서에서 제시된 다각적인 분석과 프레임워크를 바탕으로 자신의 시스템에 가장 적합한 로드 밸런싱 전략을 수립함으로써, 끊임없이 변화하는 기술 환경 속에서 지속 가능한 서비스를 구축할 수 있을 것이다.

9. 참고 자료

1. 로드 밸런싱(Load Balancing)의 개념과 특징, https://twojun-space.tistory.com/158
2. [네트워크] 로드밸런서의 기본 (L4 로드밸런서 L7 로드밸런서) (AWS ELB, NLB, ALB), https://etloveguitar.tistory.com/136
3. [IT] 로드밸런서(Load Balancer) - 쉽게 켜다 - 티스토리, https://trillium.tistory.com/124
4. [AWS] 로드 밸런서란? - 만자의 개발일지, https://yoo11052.tistory.com/63
5. 로드 밸런서(Load Balancer)란 (개념, 알고리즘 종류) - Tech Log - 티스토리, https://cb036133.tistory.com/192
6. 부하분산 - 나무위키, https://namu.wiki/w/%EB%B6%80%ED%95%98%EB%B6%84%EC%82%B0
7. www.smileshark.kr, https://www.smileshark.kr/post/what-is-a-load-balancer-a-comprehensive-guide-to-aws-load-balancer#:~:text=%EB%A1%9C%EB%93%9C%EB%B0%B8%EB%9F%B0%EC%84%9C(Load%20Balancer)%EB%8A%94,%EC%9E%91%EB%8F%99%EC%9D%84%20%EB%A9%88%EC%B6%9C%20%EC%88%98%20%EC%9E%88%EC%8A%B5%EB%8B%88%EB%8B%A4.
8. 로드 밸런싱이란 무엇인가요? - 로드 밸런싱 알고리즘 설명 - AWS, https://aws.amazon.com/ko/what-is/load-balancing/
9. [네트워크] 로드밸런싱의 개념 및 기법 설명, https://co-no.tistory.com/entry/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-%EB%A1%9C%EB%93%9C%EB%B0%B8%EB%9F%B0%EC%8B%B1
10. 로드 밸런서 (Load Balancer) - velog, https://velog.io/@corone_hi/%EB%A1%9C%EB%93%9C-%EB%B0%B8%EB%9F%B0%EC%84%9C-Load-Balancer
11. 로드 밸런싱이란? - IBM, https://www.ibm.com/kr-ko/topics/load-balancing
12. Elastic Load Balancing. 로드 밸런싱이란? | by Yuni(Yuwon) Yoon | Medium, https://medium.com/@yyuni915/elastic-load-balancing-b4a4ddad9d2d
13. 로드 밸런싱(Load balancing) - velog, https://velog.io/@sh93/%EB%A1%9C%EB%93%9C-%EB%B0%B8%EB%9F%B0%EC%8B%B1Load-balancing
14. 로드 밸런서(Load Balancer)란? 고가용성과 성능 최적화를 위한 핵심 기술, https://nosupport.tistory.com/entry/%EB%A1%9C%EB%93%9C-%EB%B0%B8%EB%9F%B0%EC%84%9C%EB%9E%80-%EA%B3%A0%EA%B0%80%EC%9A%A9%EC%84%B1%EA%B3%BC-%EC%84%B1%EB%8A%A5-%EC%B5%9C%EC%A0%81%ED%99%94%EB%A5%BC-%EC%9C%84%ED%95%9C-%ED%95%B5%EC%8B%AC-%EA%B8%B0%EC%88%A0
15. 로드 밸런싱(Load Balancing)에 대해 알아보겠습니다., https://feccle.tistory.com/m/254
16. brunch.co.kr, https://brunch.co.kr/@growthminder/149#:~:text=%EB%A1%9C%EB%93%9C%20%EB%B0%B8%EB%9F%B0%EC%8B%B1%EC%9D%98%20%EA%B8%B0%EB%B3%B8%20%EC%9B%90%EB%A6%AC,%EA%B0%80%EC%9A%A9%EC%84%B1%EC%9D%84%20%EB%86%92%EC%9D%BC%20%EC%88%98%20%EC%9E%88%EB%8B%A4.
17. 로드밸런싱의 원리와 클라우드 로드밸런싱 - 다우IDC, https://blog.daouidc.com/blog/cloud_loadbalancing
18. 로드 밸런서란 무엇인가? | F5, https://www.f5.com/ko_kr/glossary/load-balancer
19. 로드 밸런싱 알고리즘의 상세 분석과 실제 적용 사례, https://jinn-blog.tistory.com/176
20. 네트워크 - 로드 밸런서 구성 방식 - 김제리의 개발 분투기, https://jerrytheking.tistory.com/233
21. [고가용성 및 스케일링성] Elastic Load Balancing (ELB) - velog, https://velog.io/@gun_123/%EA%B3%A0%EA%B0%80%EC%9A%A9%EC%84%B1-%EB%B0%8F-%EC%8A%A4%EC%BC%80%EC%9D%BC%EB%A7%81%EC%84%B1-Elastic-Load-Balancing-ELB
22. 서버 테스트를 위한 헬스 체크(Health Check) - momomoo - 티스토리, https://momomooo.tistory.com/207
23. 로드 밸런서의 동작 방식과 로드 밸런싱 - namsick96’s blog, https://namsick96.github.io/network/load_balancer_load_balancing/
24. 로드 밸런서의 헬스 체크 - 코드 읽는 남자, https://co1nam.tistory.com/112
25. 헬스체크 - OPENMARU APM - 오픈마루, https://www.openmaru.io/tag/%ED%97%AC%EC%8A%A4%EC%B2%B4%ED%81%AC/
26. AWS ALB vs NGINX Plus Health Check 비교 분석, https://nginxstore.com/blog/aws/aws-alb-vs-nginx-plus-health-check-%EB%B9%84%EA%B5%90-%EB%B6%84%EC%84%9D/
27. Active Health Check vs Passive Health Check : 적합한 것은?, https://nginxstore.com/blog/nginx/active-health-check-vs-passive-health-check-%EC%A0%81%ED%95%A9%ED%95%9C-%EA%B2%83%EC%9D%80/
28. Health checks for Network Load Balancer target groups - AWS Documentation, https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-health-checks.html
29. API 헬스체크 - 판수개발자 - 티스토리, https://sjoongh.tistory.com/entry/API-%ED%97%AC%EC%8A%A4%EC%B2%B4%ED%81%AC
30. 로드밸런스(L4 vs L7) - exp_blog - 티스토리, https://syujisu.tistory.com/entry/%EB%A1%9C%EB%93%9C%EB%B0%B8%EB%9F%B0%EC%8A%A4L4-L7
31. HAProxy란? - 개발하는만두 - 티스토리, https://dev-youngjun.tistory.com/97
32. HAProxy 란? - Leffe’s tistory - 티스토리, https://leffept.tistory.com/309
33. [Network] Load Balancing (로드 밸런싱)의 개념과 이해, https://blog.neonkid.xyz/227
34. [네트워크] 로드밸런싱(Load Balancing) - 항상 끈기있게 - 티스토리, https://nayoungs.tistory.com/entry/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-%EB%A1%9C%EB%93%9C%EB%B0%B8%EB%9F%B0%EC%8B%B1Load-Balancing
35. [네트워크] 로드 밸런싱(Load Balancing) - 뚜발자 - 티스토리, https://s0ojin.tistory.com/17
36. Load Balancer #3 - Advanced Details of Load Balancers - 별별코딩 - 티스토리, https://yeomiikim.tistory.com/5
37. 부하 분산 알고리즘 유형 - Cloudflare, https://www.cloudflare.com/ko-kr/learning/performance/types-of-load-balancing-algorithms/
38. [Network] 로드밸런싱 알고리즘 종류 - 우노 - 티스토리, https://wooono.tistory.com/714
39. 로드 밸런싱(Load balancing) 종류와 알고리즘 | DevelopersIO, https://dev.classmethod.jp/articles/load-balancing-types-and-algorithm/
40. [Network] 로드 밸런서(LB) - 정의, 역할, 로드밸런싱 알고리즘, 종류 - 無테고리 인생살이, https://chunsubyeong.tistory.com/106
41. 로드 밸런싱 알고리즘 선택 및 가중치 구성 예시 - Tencent Cloud, https://www.tencentcloud.com/ko/document/product/214/5371
42. [란] L4 load balancer vs L7 load balancer 란? - velog, https://velog.io/@makeitcloud/%EB%9E%80-L4-load-balancer-vs-L7-load-balancer-%EB%9E%80
43. uyfuyfuy-042.tistory.com, [https://uyfuyfuy-042.tistory.com/entry/NW%EB%A1%9C%EB%93%9C%EB%B0%B8%EB%9F%B0%EC%8B%B1Round-Robin-hash#:_{:text=IP%20%ED%95%B4%EC%8B%9C%20%EB%B0%A9%EC%8B%9D%20(IP%20Hash,%ED%95%84%EC%9A%94%ED%95%9C%20%EA%B2%BD%EC%9A%B0%EC%97%90%20%EC%9C%A0%EC%9A%A9%ED%95%A9%EB%8B%88%EB%8B%A4.](https://uyfuyfuy-042.tistory.com/entry/NW로드밸런싱Round-Robin-hash#:}:text=IP 해시 방식 (IP Hash,필요한 경우에 유용합니다.)
44. What is the least response time load balancing technique? - Educative.io, https://www.educative.io/answers/what-is-the-least-response-time-load-balancing-technique
45. Least response time method | NetScaler 14.1 - Product Documentation, https://docs.netscaler.com/en-us/citrix-adc/current-release/load-balancing/load-balancing-customizing-algorithms/leastresponsetime-method.html
46. L4 / L7 로드밸런서 차이 (Load balancer) - Official-Dev. blog - 티스토리, https://jaehoney.tistory.com/73
47. L4 / L7 로드밸런서 차이점 (Load balancer) - 수 많은 우문은 현답을 만든다 - 티스토리, https://dodghek.tistory.com/33
48. [네트워크] 로드 밸런서 - 느리더라도 꾸준하게 - 티스토리, https://steady-coding.tistory.com/535
49. L4, L7 Loadbalancer 차이 - 후니의 컴퓨터 - 티스토리, https://hoony-gunputer.tistory.com/entry/L4-L7-Loadbalancer-%EC%B0%A8%EC%9D%B4
50. [네트워크] 로드밸런싱(Load Balancing) / 로드밸런서(Load Balancer) - Greyfolk99’s Studio, https://greyfolk.tistory.com/17
51. L4/L7 로드밸런싱 쉽게 이해하기 - 네트워크 엔지니어 환영 - 티스토리, https://aws-hyoh.tistory.com/149
52. SSL 트래픽 처리 방법 (SSL Termination / SSL Passthrough / SSL …, https://blog.omoknooni.me/133
53. Benefits of Offloading SSL (certs) on F5 Devices, and How to Automate it, https://www.appviewx.com/blogs/the-benefits-of-offloading-ssl-certs-on-f5-devices-and-how-to-automate-it/amp/
54. SSL Termination이란 무엇인가? - 작은 거인의 블로그 - 티스토리, https://sepiros.tistory.com/50
55. 로드밸런서 (Load Balancer) - 김GPT - 티스토리, https://kim-gpt.tistory.com/entry/%EB%A1%9C%EB%93%9C%EB%B0%B8%EB%9F%B0%EC%84%9C
56. Load Balancer 비교 - Steemit, https://steemit.com/lb/@giljae/load-balancer
57. 소프트웨어 로드 밸런서 가 더 나은 이유 - NGINX STORE, https://nginxstore.com/blog/nginx/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EB%A1%9C%EB%93%9C-%EB%B0%B8%EB%9F%B0%EC%84%9C-%EA%B0%80-%EB%8D%94-%EB%82%98%EC%9D%80-%EC%9D%B4%EC%9C%A0/
58. SW Load Balancer 테스트(1) - 이중화 테스트 - K-ECP 공식 블로그 - 한전KDN, https://kecp-cms.kdn.com/kecpblog/sw-load-balancer-%EC%97%B0%EC%86%8D%EC%84%B1-%ED%99%95%EB%B3%B4%EB%A5%BC-%EC%9C%84%ED%95%9C-%EC%9D%B4%EC%A4%91%ED%99%94-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EA%B2%B0%EA%B3%BC/
59. L4 / L7 (Load Balancing) 에 대해 알아보겠습니다., https://feccle.tistory.com/16
60. HA (High-Availability) 클러스터, Active-Active, Active-Stand by - 귀염둥이의 메모 - 티스토리, https://imjeongwoo.tistory.com/101
61. [Network] 서버 이중화 구조(Active-Active, Active-Standby) - 높고 넓은 파도 - 티스토리, https://pado-n-wave.tistory.com/35
62. [서버인프라] 서버이중화 구조(Active-Active, Active-Stand by …, https://travislife.tistory.com/47
63. HAProxy란 무엇이고 Nginx/Envoy와는 무슨 차이가 있을까? - 방로그, https://j-ho.dev/61/
64. 게이트웨이 이중화 (VRRP, GLBP) #2 - 미국사는 SRE의 일상 - 티스토리, https://ethan-world.tistory.com/entry/%EA%B2%8C%EC%9D%B4%ED%8A%B8%EC%9B%A8%EC%9D%B4-%EC%9D%B4%EC%A4%91%ED%99%94-HSRP-VRRP-GLBP-2
65. [네트워크] VRRP란? (게이트웨이 이중화 구성 - FHRP) - 공빵탈출, https://limvo.tistory.com/13
66. VRRP (Virtual Router Redundancy Protocol) - 잇찌-ITSY - 티스토리, https://wantyou7.tistory.com/entry/VRRP-Virtual-Router-Redundancy-Protocol
67. VRRP란? 네트워크 고가용성의 핵심 기술 - Connecting the Dots., https://louis-j.tistory.com/entry/VRRP-VRRP%EB%9E%80-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-%EA%B3%A0%EA%B0%80%EC%9A%A9%EC%84%B1%EC%9D%98-%ED%95%B5%EC%8B%AC-%EA%B8%B0%EC%88%A0
68. 밸런싱법: 백엔드 계획의 로드 밸런싱 가이드 - FasterCapital, https://fastercapital.com/ko/content/%EB%B0%B8%EB%9F%B0%EC%8B%B1%EB%B2%95–%EB%B0%B1%EC%97%94%EB%93%9C-%EA%B3%84%ED%9A%8D%EC%9D%98-%EB%A1%9C%EB%93%9C-%EB%B0%B8%EB%9F%B0%EC%8B%B1-%EA%B0%80%EC%9D%B4%EB%93%9C.html
69. What is Session Persistence? - F5, https://www.f5.com/glossary/session-persistence
70. [Backend] 로드 밸런서 사용 시의 이슈 중 세션 관리 문제 - Youngho’s Devlog, https://jeonyoungho.github.io/posts/%EB%A1%9C%EB%93%9C-%EB%B0%B8%EB%9F%B0%EC%84%9C-%EC%82%AC%EC%9A%A9-%EC%8B%9C%EC%9D%98-%EC%9D%B4%EC%8A%88-%EC%A4%91-%EC%84%B8%EC%85%98-%EA%B4%80%EB%A6%AC-%EB%AC%B8%EC%A0%9C/
71. ELB - Session Persistence - 코딩관계론 - 티스토리, https://bjwan-career.tistory.com/70
72. 쿠키, 세션 및 지속성 - F5, https://www.f5.com/ko_kr/resources/white-papers/cookies-sessions-and-persistence
73. Network > Load Balancer > 개요 - NHN Cloud 사용자 가이드, https://docs.nhncloud.com/ko/Network/Load%20Balancer/ko/overview/
74. [고가용성 및 스케일링성] Elastic Load Balancer - 고정 세션 (Sticky Sessions) - velog, https://velog.io/@gun_123/%EA%B3%A0%EA%B0%80%EC%9A%A9%EC%84%B1-%EB%B0%8F-%EC%8A%A4%EC%BC%80%EC%9D%BC%EB%A7%81%EC%84%B1-Elastic-Load-Balancer-%EA%B3%A0%EC%A0%95-%EC%84%B8%EC%85%98-Sticky-Sessions
75. 분산 환경에서 세션을 유지하는 방법 - ecsimsw, https://www.blog.ecsimsw.com/entry/Load-Balancing%EA%B3%BC-%EC%84%B8%EC%85%98-%EC%9C%A0%EC%A7%80-Sticky-Session-Session-Clustering
76. Infra - 로드밸런서와 세션관리, https://xggames.tistory.com/71
77. What is SSL Offloading? Definition and Related FAQs - VMware, https://www.vmware.com/topics/ssl-offload
78. SSL 오프로딩 - 씨디네트웍스, https://www.cdnetworks.com/ko/glossary/ssl-offloading/
79. What is SSL Offloading? - F5, https://www.f5.com/glossary/ssl-offloading
80. SSL 오프로딩이란? - F5, https://www.f5.com/ko_kr/glossary/ssl-offloading
81. What is SSL Offloading? Its Role in Network Security - Radware, https://www.radware.com/cyberpedia/application-delivery/ssl-offload/
82. AWS Elastic Load Balancer(ELB) 쉽게 이해하기 #1 - 네트워크 엔지니어 환영 - 티스토리, https://aws-hyoh.tistory.com/128
83. [AWS]AWS의 로드밸런서(ELB) - IT 기획의 길 - 티스토리, https://sangbeomkim.tistory.com/254
84. 4가지 로드밸런서 타입별 차이(ALB, ELB, CLB, NLB) - 욘블로그(Yon-Blog) - 티스토리, https://y-oni.tistory.com/313
85. [aws] 로드밸런서 정의, 유형 별 비교 - MILKY’s CLOUD - 티스토리, https://minjii-ya.tistory.com/56
86. Day 25 | AWS Load Balancers - Medium, https://medium.com/@csarat424/day-25-aws-load-balancers-bcc401b3d4ec
87. AWS - ALB, NLB 비교 - velog, https://velog.io/@yange/%EB%82%B4%EB%B6%80%EB%A7%9D%ED%8F%90%EC%87%84%EB%A7%9D%EC%97%90%EC%84%9C-repository-%EA%B5%AC%EC%84%B1
88. GCP : 로드 밸런싱(Load Balancing) and 오토 스케일링(Auto Scaling) - 하이프마크, https://hypemarc.com/gcp-load-balancing/
89. Cloud Load Balancing overview - Google Cloud, https://cloud.google.com/load-balancing/docs/load-balancing-overview
90. Cloud Load Balancing, https://cloud.google.com/load-balancing?hl=ko
91. [GCP] GCP 로드 밸런서와 Cloud NAT 구축 - Studying IT with cobinding - 티스토리, https://cobinding.tistory.com/246
92. [Aws cloud school 35일차]_GCP LB의 종류 - velog, https://velog.io/@minipig0218/Aws-cloud-school-35%EC%9D%BC%EC%B0%A8LB%EC%9D%98-%EC%A2%85%EB%A5%98
93. Azure Load Balancer 알고리즘, https://learn.microsoft.com/ko-kr/azure/load-balancer/concepts
94. Azure Load Balancer 공부 - velog, https://velog.io/@orpsh1941/Azure-Load-Balancer-%EA%B3%B5%EB%B6%80
95. Azure 로드밸런서 정리 - 보글보글 클라우드 - 티스토리, https://bokchi-cloud.tistory.com/13
96. Azure Load Balancer란? - Microsoft Learn, https://learn.microsoft.com/ko-kr/azure/load-balancer/load-balancer-overview
97. 부하 분산 옵션 - Azure Architecture Center - Microsoft Learn, https://learn.microsoft.com/ko-kr/azure/architecture/guide/technology-choices/load-balancing-overview
98. Gateway Offloading pattern - Azure Architecture Center | Microsoft Learn, https://learn.microsoft.com/en-us/azure/architecture/patterns/gateway-offloading
99. Azure Application Gateway Backend Settings configuration | Microsoft Learn, https://learn.microsoft.com/en-us/azure/application-gateway/configuration-http-settings
100. Virtual Machines and Networks in the Cloud - Comparing load balancing in Google Cloud and AWS, https://www.cloudskillsboost.google/course_templates/38/video/368441
101. Amazon EKS 멀티 클러스터 로드밸런싱으로 고가용성 애플리케이션 구성하기 - AWS, https://aws.amazon.com/ko/blogs/tech/build-highly-available-application-with-amazon-eks-multi-cluster-loadbalancing/
102. AWS Load Balancer vs GCP Load Balancer: A Comprehensive Comparison | by Shan’s Techie Corner | Medium, https://shanmugasundaram.in/aws-load-balancer-vs-gcp-load-balancer-a-comprehensive-comparison-864ea7d749d6
103. ALB 수준에서의 TLS 이야기 + ELB와 ALB 이야기 - 기억 안 나면 다시 보면 되지 - 티스토리, https://lsj31404.tistory.com/103
104. L4와 L7 로드밸런서의 차이점 - velog, https://velog.io/@moonblue/L4%EC%99%80-L7-%EB%A1%9C%EB%93%9C%EB%B0%B8%EB%9F%B0%EC%84%9C%EC%9D%98-%EC%B0%A8%EC%9D%B4%EC%A0%90